1. Field of the Invention
The present invention generally relates to computer software programs to be used in Financial Service Organizations. More particularly, the present invention relates to a system for modeling a Financial Service Organization (FSO) production system for processing FSO transactions.
2. Description of the Related Art
FSOs such as banks, credit unions, insurance companies, mutual fund companies, credit card companies, brokerage houses, etc., market many types of financial products to their customers, such as savings accounts, brokerage accounts, commercial loans, mortgage loans, auto loans, personal loans, and credit cards. To acquire a credit product, for example, a customer of a FSO is typically required to submit an application for the credit product. The FSO then follows an application processing procedure for the credit product to determine whether the application is approved or rejected.
The application procedure includes such steps as gathering financial related information of the customer applying for the credit product, requesting credit reports on the customer, and examining and scoring the credit product application to see if the customer's credit a product application is to be approved or rejected. This application procedure is typically referred to as account acquisition.
Another function of a FSO is the management of existing FSO credit products. Part of this function is tracking the status of a customer's credit products such as loans and credit cards to determine if the customer's payments on a credit product or products are delinquent. If the customer is delinquent in payments to a credit product for more than a certain period of time, typically 30 days, the customer may be submitted to a collections process in an attempt to resolve the customer's delinquency status. The collections process may involve many steps, such as an FSO representative calling the customer, sending delinquency notices to the customer, contacting an attorney or collections agency for funds collection, or repossession of property used to secure the credit product. The process of attempting to resolve delinquent customer accounts may be called account collections.
Account acquisition and account collections computer software programs are used in FSOs to implement account acquisition and account collection. These software programs are typically executed on mainframe-based computer systems. Collectively, these software programs executing on mainframe-based computer systems may be referred to as customer credit systems. Being mainframe-based, customer credit systems are centralized, typically with a mainframe computer including the software and databases located at a central computing center, and user workstations for accessing the software and databases distributed among local and remote offices. These workstations are typically computer terminals, or in some cases microcomputers running terminal emulation software. Mainframe-based customer credit systems are not easily scalable. If the demands on a mainframe-based customer credit system outgrow the processing, storage, or workstation support capacity of the mainframe computer, the only recourse may be to replace the existing mainframe with a new, more powerful mainframe. As mainframe systems cost from the hundreds of thousands to millions of dollars, upgrading can be very expensive. Further, downtime associated with the rollover to a new system with a larger mainframe may be disruptive to the account acquisition and account collection operations of the FSO.
Data such as credit product applications may be entered into existing customer credit systems by file access. File access involves copying files into the mainframe computer's memory or disk storage for processing by the customer credit system software. The formats of files to be read into the customer credit system are hard-coded into the system. As used herein, “hard-coded” indicates behavior that is inserted directly into a program, where it cannot be easily modified without the intervention of a computer programmer to make code changes, re-compile, and test the changes. Thus, all files copied into the mainframe for processing by the system must be in a fixed, correct format. Data may also be entered at a workstation by filling in fields on a computer screen presented on the workstation by the customer credit system. An example of data entered at a workstation is a loan application. The format and contents of an application displayed on a workstation, including titles and labels on fields, are hard-coded in the customer credit system.
Some FSO customer credit systems for implementing account acquisition and collection are static in that each customer application for product or each customer with a delinquent account is processed the same regardless of whether the customer is a new customer or an existing customer or whether the customer has an extensive and good credit history. Static account acquisition processes follow a preprogrammed, linear, fixed series of steps for all customers applying for the loan. For example, a long-term customer of a bank may apply for a credit card. The bank's customer credit system follows a fixed series of steps for all customers applying for the credit card, the first step of which is to request a full credit report from an external agency. The bank may have to pay for the credit report. If the customer has a large savings account, maintains a significant balance in a checking account, has little outstanding debt with the bank, and has a spotless credit history with the bank, it may not be necessary to request a credit report from an external agency before approving the credit card. However, since all customers are processed the same, a credit report will be requested for the customer. The same is true for the collections process. All customers entered into an account collections process in a customer credit system follow a preprogrammed, linear, fixed series of steps attempting to resolve a delinquency status.
The fixed linear hierarchy of steps in existing customer credit systems often result in redundant data entry. For example, one or more steps in the process may be to get a customer's credit history. Notwithstanding the existence of this data in the FSO's customer database, one or more of the steps require access to an external source to retrieve the same information.
Processing steps are programmed into existing customer credit system's software during the system's development. Data such as values used in approving or declining a credit product applications, time limits in the collections process, and screen formats to be presented at workstations are hard-coded into the software during the system's development. This makes customer credit systems inflexible and difficult to modify, limiting the adaptability of the systems to changing business environments. The process to modify a customer credit system typically requires the following steps: officers of the FSO determining the changes to be made to the system; communicating the changes to the Information Technology department of the FSO; systems analysts in the Information Technology department creating software design and specification documents; a team of software engineers modifying and compiling source code based upon the design and specification documents; database analysts modifying databases to meet the new specifications; testing and verification of the modified system, and; operations personnel replacing the customer credit system production system. This modification process is time-consuming and expensive, and may take months or even years to complete. Some desired changes may be lost or modified in the process of transferring the desired changes from business officers to source code changes. Business requirements may change during the modification process, requiring either a delay in the modification process so that new requirements can be added, or starting a new modification process overlapping the modification process in progress.
Existing customer credit systems are mainframe-based and are therefore not easily scalable. It is therefore desirable to provide a customer credit system that is easily scalable to meet increased processing demands in an FSO. Modifying existing customer credit systems to meet changing business needs is a long process requiring many steps, including code changes by programmers that may have limited business knowledge in the customer credit marketplace. It is therefore desirable to provide a customer credit system that may be modified quickly and easily by business officers that understand the customer credit marketplace and know what changes need to be made to address changes in the marketplace. All customers are treated the same in an existing customer credit system, regardless of the customers' current or previous history with the FSO. It is therefore desirable to provide a customer-centric customer credit system that may be tailored to handle customer transactions dynamically, allowing different customer credit strategies to be applied to customers with distinctly different credit profiles.
Current customer credit system software is designed in one step on paper and later implemented in computer programming languages. This makes it difficult to visualize the credit product processing actually implemented in the customer credit system software. It is therefore desirable to provide an integrated, graphical design and implementation process to better visualize and understand the credit product processing implemented in the system. Current customer credit system software also does not provide a way to model the business structure of a FSO. It is therefore desirable to provide a modeling tool for describing the business structure of a FSO, and for describing the credit product processing relationships among the organizational units in the FSO. It is also desirable to provide a method for adapting a customer credit system to a variety of credit products, including developing custom documents such as product applications and correspondence and developing custom product processing strategies, without a lengthy design and coding process.
The following is hereby incorporated by reference: Method for performing operations on informational objects by visually applying the processes defined in utility objects in an IT (information technology) architecture visual model (U.S. Pat. No. 6,091,893), System and method for providing a high level language for mapping and accessing objects in data stores (U.S. Pat. No. 6,061,515), Goal based tutoring system with behavior to control flow of presentation (U.S. Pat. No. 6,023,692), and Decentralized distributed asynchronous object oriented system and method for electronic data management, storage, and communication (U.S. Pat. No. 5,550,976).